System and method for performing data retention in solid-state memory using copy commands and validity and usage data

ABSTRACT

Systems and methods for retaining data in non-volatile solid-state are disclosed in which refresh copy operations are performed on data stored in non-volatile solid-state memory. A controller can comprise a data retention module configured to issue copy commands within different periods of time, and to maintain usage data on a storage subsystem. A refresh copy operation helps ensure that data written to memory retain integrity by causing data to be programmed again onto the memory, which minimizes the risk of data error caused by electron leak in the non-volatile solid-state memory. One or more data structures may be used to determine memory blocks that require refresh copy operations. In one embodiment, a validity bit array is used to track blocks that contain valid data. In another embodiment, a least recently used list is used to track blocks that have been least recently written.

BACKGROUND

Non-volatile solid-state memory stores data, at the hardware level, byretaining electrons at individual floating gates within memory cells.The electrons are placed into the floating gates by a current appliedduring a program cycle. If a floating gate in the programmed state isleft un-programmed for a long time, some of the electrons may leak outof the floating gate and cause bit errors.

BRIEF DESCRIPTION OF THE DRAWINGS

Systems and methods which embody the various features of the inventionwill now be described with reference to the following drawings, inwhich:

FIG. 1A is a block diagram illustrating a solid-state storage subsystemaccording to one embodiment.

FIG. 1B illustrates data retention methods according to variousembodiments.

FIG. 2A illustrates an example of using validity bit arrays in a dataretention operation in accordance with one embodiment.

FIG. 2B is a flow diagram showing the process of updating the validitybit arrays in accordance with one embodiment.

FIG. 2C is a flow diagram showing the process of using the validity bitarrays in the data retention operation in accordance with oneembodiment.

FIG. 3A illustrates another example of using validity bit arrays in adata retention operation in accordance with one embodiment.

FIG. 3B is a flow diagram showing the process of updating the validitybit arrays in accordance with another embodiment.

FIG. 3C is a flow diagram showing the process of using the validity bitarrays in the data retention operation in accordance with anotherembodiment.

FIG. 4 is a flow diagram illustrating a process of updating a leastrecently used list of blocks in accordance with one embodiment.

FIG. 5 is a flow diagram illustrating a process of performing dataretention with a least recently used list of blocks in accordance withone embodiment.

DETAILED DESCRIPTION

While certain embodiments of the invention have been described, theseembodiments have been presented by way of example only, and are notintended to limit the scope of the invention. Indeed, the novel methodsand systems described herein may be embodied in a variety of otherforms. Furthermore, various omissions, substitutions and changes in theform of the methods and systems described herein may be made withoutdeparting from the spirit of the invention. The accompanying claims andtheir equivalents are intended to cover such forms or modifications aswould fall within the scope and spirit of the inventions.

Overview

Embodiments of the invention are directed to systems and methods forretaining data in solid-state memory in which refresh copy operationsare performed on data stored in solid-state memory. A refresh copyoperation helps ensure that data written to memory retain integrity bycausing data to be programmed again onto the memory, which minimizes theaforementioned risk of data error caused by electron leak. One or moredata structures may be used to determine memory blocks that requirerefresh copy operations. For example, in one embodiment, a validity bitarray is used to track blocks that contain valid data. In anotherembodiment, a least recently used list is used to track blocks that havebeen least recently written.

System Overview

FIG. 1A is a block diagram illustrating a storage subsystem embodimentwith a data retention capability. As shown, a storage subsystem 140includes a controller 150, which in turn includes a command queue 142and a data retention module 148, which is configured to execute the dataretention operations as further described below. In one embodiment, thehost command queue 142 receives memory commands from a driver 132residing within a host system 130, and the memory commands may includewrite and read commands issued by the host system 130. As further shownin FIG. 1A, in one embodiment, the controller 150 executes the commandsin the host command queue 142 as well as commands issued by the dataretention module 148 in one or more non-volatile solid-state memoryarrays 160. The commands from the data retention module 148 may bestored in the queue 142 or in a separate queue. In the descriptionbelow, for the sake of brevity, the data retention module 148 may bedescribed as directly performing a memory operation on data in the array(e.g. copying) instead of providing a command for doing so.

Data Retention Operations

FIG. 1B illustrates data retention methods according to variousembodiments. Block diagram 202 shows a time-based embodiment in whichblocks 210 within the non-volatile memory are sequentially refreshed ona periodic basis (i.e. by refreshing one or more blocks per refreshcycle) until all blocks are refreshed. The refresh cycle in oneembodiment can be determined by dividing a refresh period by the numberof blocks to be refreshed. In one embodiment, the refresh period can beset at three months, six months, one year, etc., as based on themanufacturer's specification and/or warranty of the memory. In oneembodiment, the refresh copy commands are executed when the memory isidle (e.g. no host and/or garbage collection commands are executed). Inone embodiment, the execution of refresh copy commands may be delayed ashost commands and/or other internal commands (e.g. wear levelingcommands) are prioritized by the controller over the refresh copycommands. In one embodiment, the pace of executing the refresh copycommands is adjusted in accordance with the progress of executing therefresh copy commands within the refresh period. For example, if therefresh period is three months and the refresh copy commands are not ontrack to finish within three months, the remaining refresh copy commandsmay be prioritized for execution.

Block diagram 204 shows a data retention embodiment that uses one ormore validity bit arrays to track blocks that have valid data storedtherein. In one embodiment, the data retention module 148 consults avalidity bit array as it performs the data retention operation. Asshown, each block has a validity bit entry in each array, with the bitset to “1” if the corresponding block contains valid data and “0” if itdoes not. In other embodiments, a “1” bit indicates invalid data and a“0” bit indicates valid data. In one or more embodiments, validity bitarrays 212 and 214 are used. The two-array embodiments allow the dataretention module 148 to perform data retention operations based on thevalidity indications in one array while the other array is used to tracknew validity changes. The various data retention embodiments based onvalidity bit arrays will be further described below in conjunction withFIGS. 2A-2C and 3A-3C. In other embodiments, one validity bit array isused in the data retention operation.

Block diagram 206 shows a data retention embodiment that uses a table216 that keeps track of the least recently used (written) blocks in thesolid-state memory. In one embodiment, the table 216 lists blocks sortedby a least recently used (LRU) criterion. In one embodiment, each time ablock is written, the entry corresponding to the written block is movedfrom its current position in the table 216 to the bottom of the table.In this manner, entries for blocks that are least recently used rise tothe top, and other entries become sorted by a LRU criterion. In oneembodiment, the data retention module 148 performs data retention onblocks referenced by entries between a head pointer 218 and a tailpointer 220. In one embodiment, the entry of the block that undergoesdata retention is moved to the bottom of the table 216. In oneembodiment, once data retention module 148 processes all the blocksbetween the head and the tail pointers, the head pointer is moved to theentry after the previous location of the tail pointer, and the tailpointer is moved to the end of the table. In other embodiments, otherdata structures such as a linked list can be used to keep track of theblocks sorted by the LRU criterion. The LRU-based data retentionembodiment will be further described below in conjunction with FIGS.4-5.

Validity Bit Array Embodiments

FIG. 2A is a block diagram that illustrates an example of using validitybit arrays in a data retention operation in accordance with oneembodiment. Scenario 230 illustrates an initialization phase with thearray 212 (marked as the “current” array) and the array 214 ((marked asthe “next” array). Scenario 232 shows that during a first refreshperiod, the “current” array 212 records indications of changes in thevalidity of the data in the blocks. In the example shown, each block hasa validity bit entry in the array, with the bit set to “1” if thecorresponding block contains valid data and “0” if it does not. In otherembodiments, a “1” bit indicates invalid data and a “0” bit indicatesvalid data. The “next” array 214 in scenario 232 remains unchanged whilethe “current” array 212 is updated. Scenario 234 shows the arrays justbefore the start of the data retention operation. At the start of theoperation, the data retention module 148 copies the contents of the“current” array 212 to the “next” array 214. The data retention module148 then executes the data retention operation by consulting the“current” array 212. While the data retention operation is ongoing, thearrays record indications of changes in the validity of the data inaccordance with the process shown in FIG. 2B. Scenario 236 shows the endof the data retention operation, and the arrays are switched, with the“current” array becoming the new “next” array and the “next” arraybecoming the new “current” array. Scenario 238 shows that new validitychanges are recorded in the new “current” array until the next dataretention operation. Scenario 240 shows the start of the next dataretention operation, with the contents of the “current” array beingcopied to the “next” array and the data retention operation proceedingin accordance with the validity indications within the “current” array.

FIG. 2B is a flow diagram showing a process 300 performed by the dataretention module 148 to update the validity bit arrays in accordancewith one embodiment. In block 302, the process 300 is triggered by a newmemory operation (e.g. a new host write or a garbage collectionoperation). Then in block 304, the process determines if the dataretention operation is currently being executed. If not, the updateprocess records the validity change caused by the new memory operationin the “current” bit array in block 306. If so, the process determinesin block 308 if the new memory operation is a write operation or anerase operation. If it is a write operation, the update process recordsthe validity change caused by the new operation in the “next” bit arrayin block 310. If it is an erase operation, the process furtherdetermines in block 312 if the location of the block to be erased isahead of the location currently being processed by the data retentionoperation. If not, the update process records the validity change causedby the new memory operation in the “next” bit array in block 314. If so,the update process records the validity change caused by the new memoryoperation in the “current” and “next” bit arrays in block 316. As statedabove, since a new erase operation makes the data in the block invalid,recording the validity change in the “current” array prevents thepending data retention operation from needlessly refreshing invaliddata.

FIG. 2C is a flow diagram showing a process 400 performed by the dataretention module 148 that uses the validity bit arrays in the dataretention operation in accordance with one embodiment. In block 402, theprocess begins by copying contents of the “current” bit array to the“next” bit array. In block 404, the data retention operation begins, andthe “current” bit array entries are consulted to determine if refreshoperations (copy operations) are needed for the individual blocks. Inblock 406, the process determines if the current bit in the arrayindicates valid data in the referenced memory block and a need for arefresh copy. If so, data in the referenced memory block are copied to anew physical block in block 408. If not, the process moves to block 410.In block 410, the process checks if there are additional bits remainingin the array. If so, it moves to consult the next bit in block 406.Optionally, a timer is used in block 412 to trigger the next iterationof operation to ensure that the refresh copy operation is performed on aperiodic basis. In one embodiment, each refresh cycle is timed to ensureall refresh operations for the blocks complete within a time period setin accordance with a manufacturer warranty and/or specification. Thetime period can be for example, three months, six months, one year, etc.After all the bits are consulted in the “current” array and it isdetermined that there are no more bits remaining at block 410, the bitarrays are switched so the “current” array becomes the “next” array andvice versa at block 414. The data retention operation ends in block 416.

FIG. 3A is a block diagram that illustrates another example of usingvalidity bit arrays in a data retention operation in accordance with oneembodiment. Scenario 430 illustrates an initialization phase with thearray 212 (marked as the “current” array) and the array 214 (marked asthe “next” array). Scenario 432 shows that during a first refreshperiod, the “next” array 214 records indications of changes in thevalidity of the data in the blocks. The “current” array 212 in scenario432 remains unchanged while the “next” array 214 is updated. Scenario434 shows the arrays just before the start of the data retentionoperation. At the start of the operation, the data retention module 148copies the contents of the “next” array 214 to the “current” array 212,and then switches the two arrays by making array 212 the “next” arrayand array 214 the “current” array. The data retention module 148 thenexecutes the data retention operation by consulting the “current” array212. While the operation is ongoing, the arrays record indications ofchanges in the validity of the data in accordance with the process shownin FIG. 3B. Scenario 436 shows the arrays at the end of the dataretention operation. Scenario 438 shows that new validity changes arerecorded in the “next” array 212 until the next data retentionoperation. Scenario 440 shows the start of the next data retentionoperation, in which the data retention module 148 again performs thecopying and switching of arrays as previously shown in scenario 434prior to executing the data retention operation.

FIG. 3B is a flow diagram showing a process 500 performed by the dataretention module 148 to update the validity bit arrays in accordancewith one embodiment. In block 502, the process 500 is triggered by a newmemory operation (e.g. a new host write or a garbage collectionoperation). Then in block 504, the process determines if the dataretention operation is currently being executed. If not, the updateprocess records the validity change caused by the new memory operationin the “next” bit array in block 506. If so, the process determines inblock 508 if the new memory operation is a write operation or an eraseoperation. If it is a write operation, the update process records thevalidity change caused by the new operation in the “next” bit array inblock 510. If it is an erase operation, the process further determinesin block 512 if the location of the block to be erased is ahead of thelocation currently being processed by the data retention operation. Ifnot, the update process records the validity change caused by the newmemory operation in the “next” bit array in block 514. If so, the updateprocess records the validity change caused by the new memory operationin the “current” and “next” bit arrays in block 516.

FIG. 3C is a flow diagram showing a process 600 performed by the dataretention module 148 that uses the validity bit arrays in the dataretention operation in accordance with one embodiment. In block 602, theprocess begins by copying contents of the “next” bit array to the“current” bit array. In block 604, the arrays are switched so the “next”array becomes the “current” array and vice versa. In block 606, the dataretention operation begins, and the “current” bit array entries areconsulted to determine if refresh operations (copy operations) areneeded for the individual blocks. In block 608, the process determinesif the current bit in the array indicates a need for a refresh copy inthe referenced memory block. If so, data in the referenced memory blockare copied to a new physical block in block 610. If not, the processmoves to block 612. In block 612, the process checks if there areadditional bits remaining in the array. If so, it moves to consult thenext bit in block 608. As with the process shown in FIG. 2C, optionally,a timer is used in block 614 to trigger the next iteration to ensurethat the refresh copy operation is performed on a periodic basis. Afterall the bits are consulted in the “current” array, the data retentionoperation ends in block 616.

Least Recently Used Based Embodiment

FIG. 4 is a flow diagram illustrating a process 700 performed by thedata retention module 148 for updating a LRU list used in a dataretention operation in accordance with one embodiment. In block 702, theprocess 700 is triggered by a new memory operation (e.g. a new hostwrite or a garbage collection operation). Then in block 704, the processdetermines if the new memory operation is a write operation or an eraseoperation. If it is a write operation, the update process 700 recordsthe validity change caused by the new memory operation by moving anentry referencing the written block to the bottom of the LRU list inblock 706. If it is an erase operation, the process records the validitychange caused by the new memory operation by removing the entryreferencing the erased block from the LRU list in block 708. If the sameblock is written to in the future, it will be added back into the LRUlist (at the bottom of the list). In another embodiment, no change tothe list is made in block 708.

FIG. 5 is a flow diagram illustrating a process 800 performed by thedata retention module 148 for performing data retention with a leastrecently used list (or table) of blocks in accordance with oneembodiment. The process 800 begins at block 802. Then in block 804, thetop entry on the LRU list within range of the head and tail pointers isprocessed. The head and tail pointers (218 and 220) were previouslyshown in FIG. 1B, and as discussed above, mark the range of blocks thatwill undergo the data retention operation. In block 806, the process 800copies data in the corresponding block referenced by the particularentry in the LRU list to a new physical location. Then in block 808, theentry is moved to the bottom of the LRU list, which may be outside ofthe range of the head and tail pointers. The process 800 then determinesif there are additional entries remaining between the head and tailpointers, and if so, proceeds to the next entry at block 804.Optionally, a timer may be used to trigger the next iteration in block812. In one embodiment, each refresh cycle is timed to ensure allrefresh operations for the blocks complete with a time period set inaccordance with a manufacturer warranty and/or specification. The timeperiod can be, for example, three months, six months, one year, etc.Once the entries between the head and tail pointers are processed, theprocess in block 814 moves or sets the locations of the head and tailpointers for the next data retention operation. In one embodiment, thehead pointer is moved to the entry after the previous location of thetail pointer and the tail pointer is moved to the end of the table. Theoperation ends in block 816.

In various embodiments, the different data retention operationsdescribed above may be modified. For example, the data retention modulemay switch among the different types of data retention operations orperform operations that use more than one data structure described above(e.g. using both the LRU list and the validity data bit arrays).

CONCLUSION

The features and attributes of the specific embodiments disclosed abovemay be combined in different ways to form additional embodiments, all ofwhich fall within the scope of the present disclosure. Although thepresent disclosure provides certain embodiments and applications, otherembodiments that will be apparent to those of ordinary skill in the art,including embodiments which do not provide all of the features andadvantages set forth herein, are also within the scope of thisdisclosure. Accordingly, the scope of the present disclosure is intendedto be defined only by reference to the appended claims.

What is claimed is:
 1. A storage subsystem, comprising: a non-volatilesolid-state memory array; and a controller comprising a data retentionmodule, the data retention module configured to: issue a plurality ofcopy commands for copying data stored in physical memory locations,within the non-volatile solid-state memory array, that are selected bythe data retention module; maintain usage data on the storage subsystem;maintain a first data structure comprising a plurality of validityindications for corresponding physical memory locations in thenon-volatile solid-state memory array, the indications reflectingwhether the corresponding physical memory locations contain valid data;and use the first data structure to determine the selected physicalmemory locations so that the copy commands are issued for physicalmemory locations indicated by the first data structure as containingvalid data, wherein the data retention module is further configured toissue the copy commands so that the data in the selected physical memorylocations are copied at least once within a first period of timedetermined by the data retention module based on the usage data.
 2. Thestorage subsystem of claim 1, wherein the copy commands are issuedindependent of a command issued by a host system from which the storagesubsystem is configured to receive commands.
 3. The storage subsystem ofclaim 1, wherein the usage data comprises a number of program and erasecycles that the non-volatile solid-state memory array has experienced.4. The storage subsystem of claim 1, wherein the first data structurecomprises a bit array.
 5. The storage subsystem of claim 1, wherein thecontroller is configured to prioritize the copy commands for executionwhen it is determined that a time period remaining in the first periodof time is shorter than a time period needed to complete copy commandsfor the remaining physical memory locations indicated by the first datastructure as containing valid data.
 6. The storage subsystem of claim 1,wherein the data retention module is further configured to issue thecopy commands when the controller is not processing a memory command. 7.The storage subsystem of claim 1, wherein the selected physical memorylocations comprise physical memory locations for the entire non-volatilesolid-state memory array.
 8. The storage subsystem of claim 7, whereineach of the plurality of copy commands is issued periodically in a timeinterval determined by dividing the first period of time by a number ofphysical memory locations in the non-volatile solid-state memory array.9. The storage subsystem of claim 1, wherein the first period of time isthree months.
 10. The storage subsystem of claim 9, wherein the usagedata comprises an amount of time during which the storage subsystem ispowered on.
 11. The storage subsystem of claim 1, wherein the dataretention module is further configured to update the first datastructure when the controller executes a command other than one of theplurality of copy commands on the non-volatile solid-state memory arrayto reflect a change in validity caused by execution of the command otherthan one of the plurality of copy commands.
 12. The storage subsystem ofclaim 11, wherein the data retention module is further configured to:issue the plurality of copy commands within a second period of time thatis shorter than the first period of time; and within the second periodof time when the controller executes a command other than one of theplurality of copy commands on the non-volatile solid-state memory array,update a second data structure comprising validity indications forcorresponding physical memory locations in the non-volatile solid-statememory array.
 13. The storage subsystem of claim 12, wherein the dataretention module is further configured to use the second data structureafter the end of the second period of time to determine the selectedphysical memory locations.
 14. The storage subsystem of claim 1, whereinthe data retention module is further configured to maintain a list ofphysical memory locations in the non-volatile solid-state memory sortedby a least recently used (LRU) criterion and use the list to selectphysical memory locations for the copy commands.
 15. The storagesubsystem of claim 14, wherein the list of physical memory locations isimplemented as a linked list.
 16. A method of retaining data innon-volatile solid-state memory, the method comprising: selecting aplurality of physical memory locations within the non-volatilesolid-state memory; issuing a plurality of copy commands for copyingdata stored in the selected physical memory locations within thenon-volatile solid-state memory; maintaining usage data on a storagesubsystem which comprises the non-volatile solid-state memory; using theusage data to determine a first period of time, wherein the copycommands are issued so that data in the selected physical memorylocations are copied at least once within the first period of time;maintaining a first data structure comprising a plurality of validityindications for corresponding physical memory locations in thenon-volatile solid-state memory, the indications reflecting whether thecorresponding physical memory locations contain valid data; and usingthe first data structure to determine the selected physical memorylocations so that the copy commands are issued for physical memorylocations indicated by the first data structure as containing validdata.
 17. The method of claim 16, wherein the usage data comprises anumber of program and erase cycles that the non-volatile solid-statememory has experienced.
 18. The method of claim 16, further comprising:updating the first data structure when a command other than one of theplurality of copy commands is executed on the non-volatile solid-statememory to reflect a change in validity caused by execution of thecommand other than one of the plurality of copy commands.
 19. The methodof claim 16, wherein the first data structure comprises a bit array. 20.The method of claim 16, further comprising: prioritizing the copycommands for execution when it is determined that a time periodremaining in the first period of time is shorter than a time periodneeded to complete copy commands for the remaining physical memorylocations indicated by the first data structure as containing validdata.
 21. The method of claim 16, wherein issuing a plurality of copycommands for copying data stored at the selected physical memorylocations further comprises issuing the copy commands when no memorycommand is being executed in the non-volatile solid-state memory. 22.The method of claim 16, wherein the selected physical memory locationscomprise physical memory locations for the entire non-volatilesolid-state memory.
 23. The method of claim 22, wherein the issuingcomprises periodically issuing each of the plurality of copy commands ina time interval determined by dividing the first period of time by anumber of physical memory locations in the non-volatile solid-statememory.
 24. The method of claim 16, wherein the first period of time isthree months.
 25. The method of claim 24, wherein the usage datacomprises an amount of time during which the storage subsystem ispowered on.
 26. The method of claim 16, wherein the issuing comprisesissuing the plurality of copy commands within a second period of timethat is shorter than the first period of time and the method furthercomprises: within the second period of time when a command other thanone of the plurality of copy commands is executed on the non-volatilesolid-state memory, updating a second data structure comprising validityindications for corresponding physical memory locations in thenon-volatile solid-state memory.
 27. The method of claim 26, wherein theselecting comprises using the second data structure after the end of thesecond period of time to determine the selected physical memorylocations.
 28. The method of claim 16, further comprising: maintaining alist of physical memory locations in the non-volatile solid-state memorysorted by a least recently used (LRU) criterion, wherein the selectingcomprises using the list to select physical memory locations for thecopy commands.
 29. The method of claim 28, wherein the list of physicalmemory locations is implemented as a linked list.